Hey-ho, here we go again. Another short demo by me, so that I can embarass myself in front of everybody.
This time I’ve spend a few hours making a 3d-starfield. It’s old news, easy to do and very slow. It’s free too, so that’s alright.
I made this because I needed something to check how well double buffering worked on the Mac (answer: very well indeed). In a way I suppose the double buffering is the most interesting thing in this demo so obviously I haven’t made it: those clever Lightsoft guys did.
The program should run in most resolutions at 256 colours. Give it a try.
Anyway, here’s how everything else works...
How it works.
I suppose I should start from scratch, but that would take *way* too much time. So I’m assuming you know about 3d coordinates and stuff like that.
First thing we do is to make a table of coordinates. Each set of coordinates refer to 1 star. A set of coordinates looks like this: X,Y,Z. Each of the coordinates is a halfword, so a table containing 800 stars would have a size of: number_of_stars*3*2.
The table is made using the Random function. Remember to mask the number, so that coordinates wont be out of bounds.
Remember to calculate this outside the mainloop. Random is a slow routine.
Having calculated all the coords we can begin our mainloop.
The mainloop begins with an error ;-) Will explain later.
I start by converting the 3d coordinates to 2d. The formula is:
x2D = (x*const)/z
y2D = (y*const)/z
Pretty basic stuff. I subtract and add a few number to center the stars on the screen.
Now I decrease Z to make the stars come closer to the screen. This is the error. This should probably be done *before* we convert the stars to 2d. It doesn’t really matter, but the correct way would be to do the moving before the converting.
Having done all this, we are ready to plot the stars. As we plot the stars we convert the Z coordinate to a colournumber, so that stars that are far away are darker than those that are closest. Also this prevents the stars from 'popping' up when they are reset at a new Z-value.
The double buffer system (and some other stuff) was made by Lightsoft. I haven’t changed much, except making it a little more readable and thereby making it a bit slower :-)
If you want, it would be easy to convert the screen dimensions to something else. Well, in theory, anyway. Some of the doublebuffer routine (splat_screen) is pretty hardwired, I suppose I’ll have to make my own.
It’s very fast, though. Everybody: Thank you Lightsoft!
Tech notes.
The stars themselves doesn’t appear to be especially fast. You can add a few thousand stars more without slowing the program down noticeably, but it could/should be a lot faster.
I suppose this is due to several factors:
a) I divide and multiply a bit too much. Some of them could be removed or optimized to shifts.
b) I’m not sure that the bounds cheking is optimal. I’m sure it’s possible to do it another way.
c) The 3d-> 2d routine probably isn’t optimal as well.
...mmm, and not much more I can think of. Any suggestions would be welcome.
I think you can make some weird effects by not clearing the offscreen each loop. This will make the stars leave trails, which might look nice. Haven't tried it.
I suppose you can, with the aid of a few cos and sinus-tables, make the stars move in a more interesting way. Rotate them or something.
Final notes.
Right! That was stars. Been there, done that, got the t-shirt.
I suppose I’ll have to do something interesting next time (polygons sounds interesting). Or perhaps I’ll start on that mega-demo. That would be fun :)
Feel free to contact me about anything. I’m at:
E-mail:
2811aj@fiol.brock.dk
or
maccoder@geocities.com
Try: http://www.geocities.com/SiliconValley/4889/ (will be running soon(ish))
Allan
P.S. Oh yeah, do with this what you want, only don’t expect me to buy you a new Mac when this one explodes due to my bad programming.
